Celestin Apprentice 7/Apprentice-Release7.iso/Source Code/C/Frameworks/Hsoi's App Shell 1.0a4/0.9a2->1.0a1->1.0a2 notes

Text File | 1996-03-21 | 34.2 KB | 611 lines | [TEXT/CWIE]

Friday July 7, 1995 @ 1:07pm

*+*+*+*+*+*+*+*+*+*+*+*+*+*+*    THINGS TO DO    *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

This is a listing of the things that still need to get done before the next
release of the shell (0.9a3).  No particular order, just stuff to impliment, fix,
brush up, etc etc.

•    General brushing up of code:  remove redundant stuff, optimize, go through snippets
    that i just copied and pasted and clean it up to work right (like the modal dialog
    stuff)

    Also, just make sure everything works right and acts like it should.  Plus, make
    sure things don't work one way here and anothe way there (if they're doing
    the same sort of stuff).  Consistancy!

•    Comment the code:  remove verbose stuff, rewrite for clarity and conciseness, make
    sure all things are commented well.  This goes along with writing the docs

•    some Balloon help (no way do i want to impliment balloon's everywhere, but just
    enough so all balloon types are covered and people can see how to do them)

•    AppleScript support...fully scriptable, fully recordable, and maybe even some of
    my own things.  I have some stuff (taken straight from the WASTE Demo) but
    that's not enough.

•    Edition Manager support

•    Get that little prefs size popup/editbox problem fixed, and make the dialog filter
    filter out non-numeric keys

•    Redo the prefs dialogs for better cosmetics (make it look better).  Add a "save"
    button to immediately save the prefs to the prefs file.  Add a "Revert" command
    and/or a "Factory Settings" button.  Also, develop magazine had a great article
    on writing multi-pane dialogs.  I might want to scrap my prefs code as it is
    now and redo things with that...

•    Impliment a "Find" dialog to find text.  This'll give the modeless dialog box a
    purpose in life.

•    Make the dialog stuff in HsoiEventLoop() a little more robust (but not necesary
    until the Find dialog gets implimented really)

•    Use PickColor() instead of GetColor().  And I think PickColor() is a System 7.5
    thing, so we'll have to check for this.  Marco said he'd send me his Style code
    so we can wait until then to see how he did it

    on this note, should the prefs dialog maybe impliment a popup menu for the color?
    just like the size popup...you can pick from 7 colors (like the color menu) or
    pick other (and then GetColor).  still tho, have the little color box there to
    easily display the chosen color

•    Check how well color works on b/w and grayscale monitors

•    Going with my desire for consistancy (especially with naming conventions), variable
    names in functions (and globals and statics) should be renamed so all is consistant
    (g for global, s for static, don't call it windowPtr and windowP and wp in different
    places, call it like theWindow or something in every place)

•    Documentation

•    Rewrite the licensing agreement.  See the July 95 MacTech for ideas. (mostly, i seem
    really anal about things...loosen up)

•    Better and more robust error handling.  Maybe even also put in debug stuff, like
    #ifdef DEBUG, then do things with DebugStr or ASSERTS or whatever.

    NOTE!  error handling is pretty much rewritten and improved upon, but I'm sure that
    it could always be better.  So, the only thing for this bullet-point to really
    stil do is maybe add that DEBUG stuff.

•    make sure that we always handle possible error checking situations.  i know i
    don't check in every place needed, and it's especially important in low memory
    situations (e.g. memFullErr's).  not only report possible low memory or not enough
    memory situations to users, but also see about implimenting a good low mem
    handling scheme (snag a good portion of the app heap to just hold, lock it
    hi in memory, if we get low on memory, free it up, etc)

•    Make sure that the cool about box code is as stand alone as possible.  Meaning:
    if i just take the file "HAS CoolAboutBox.c" and drop it into another project
    (and make the proper mods to my menu stuff to allow for opt-click), it'd run
    just fine...no need to make sure they have the header files (#ifndefs), no need
    to link to other code, etc

•    xDEFs

•    Get the PDOC AppleEvent (Print) working!

•    Text to speech stuff

•    PICTs (or icons or whatever) for buttons

•    Drag and drop is working (all of the WASTE Object Handlers are working).  I need to
    impliment the rest of the possible stuff (like those sound routines).

•    Spruce up the regular about box a lot more...it's really boring.  Also, rewrite
    the help file a bit more....take what's in there and use that for various
    README's and docs that'll be written out and offline.

    Things should be like this:

    Help:    actually give online help...the help will be nowhere as robust as any
            of the docs that i write, but enough to get people around while running
            the app, plus point out neat=o things that you can do (like it's not
            obivous that the notification manager will kick in, so note that, etc).

    CoolAboutBox:    stuff that needs to be dealt with for the Shell itself (i.e. if
            HAS is used in writing some software project, things needed for that.  like
            to give info, to give rule and reg info (not only mine, but also so that
            i cover ones i need to like for WASTE)).

    About:    Actual about stuff, like credits (copyright stuff, etc), registration info,
            try not to be redundant.

•    don't forget to update the comments, thanx and other stuff in the documentation
    helps and cool about box.  i remembered to add in the 1996 to the copyright
    stuff (love this new year stuff!).  But one thing that should definately be
    added is a comment about people aquiring code from Tom Bender.  a great
    learning tool.

•    redo the structure of the code and files.  try to make things more standalone.
    like how Tom Bender and John Norstad did things.  functions that are totally
    reusable (anyone could use/reuse them in any situation, like HsoiForgetHandle())
    put them in their own files.  functions that are partially reusable (like
    perhaps HsoiGetWindowWE() or something..basically, functions that are reusable
    as is, but might rely on something else, like WASTE) put them somewhere else.
    and functions that are totally HAS specific put somewhere else.  basically,
    try to make it more like a shell.

    this also means, no more big bulk header files...each file would have it's
    own header file (HASFiles.c HASFiles.h HASUtilFiles.c HASUtilFiles.h), and
    a general restructuring of the entire layout of HAS.



*+*+*+*+*+*+*+*+*+*+*+*+*+*+*    THINGS DONE        *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

These are things that have been done sine the 0.9a2 release of the app shell.

ADDED:    All keywords (mostly variable names) should now appear in color (green)

ADDED:    All HAS files written or modified enough by me (e.g. main.c, ZoomCode.c) have
        been renamed to HAS xxx.c (e.g. HAS Main.c, HASZoomCode.c).  This is to allow
        for easy identification of Shell files.  Things with their own naming convention
        (e.g. WASTE) have been left alone

ADDED:    All HAS functions have been renamed to Hsoixxx() (e.g. Initialize() to HsoiInitialize())
        This is to allow for easy identification of non-toolbox functions.  If it's not
        a toolbox call, it should have some sort of prefix on it (Hsoi for me, WE for WASTE)
        That which can't be renamed but isn't toolbox is noted with a comment as to what
        it is

PARTIALLY ADDED:    #ifndef's added in some places to allow for conditional #includes of
        header files (depending on the precompiled header).  Need to make this fully done

FIXED:    "Save Changes" Alert alert stage info has been fixed to beep properly

ADDED:    About box now plays a random sound when brought up (no point other than to
        show a neat randomization technique)

REMOVED:    All references to Hsoi's App SHOP.  Should all be SHELL now

PARTIALLY ADDED:    #ifndef's added in some places to conditionally #include or not
        header files (depending on the precompiled header).  Need to get all the files
        to be like this

ADDED:    The movablemodal progress bar now can be dismissed via cmd-.

ADDED:    Preferences!  THanx to John Norstad and the NewsWatcher source code.

FIXED:    Windows now deactivate properly when the cool about box is brought up

CHANGED:    Any header-type things for WASTE (like IC support) moved to the precompiled
        header instead of modifying WASTEIntf.h

CHANGED:    With the above, if a file is now read-only, the caret is hid

FIXED:    Window sizing now works right! (finally)  When CreateWindow() is called, windows
        properly are sized for WYSIWYG, staggering of subsequent windows works right (and
        is handled by the toolbox), printing routines modified to be consistant.

        With further progress on the shell (i got things working right, then changed
        a bunch of stuff, trashed old ways, etc etc), window sizing again works right.
        plus, window zooming is smart now.

CHANGED:    header files reorganized, constants are now enums instead of #defines. Macros
        brushed up to display conform to this.  constants and stuff renamed with prefixes
        to make things consistant

ADDED:    Notification Manager support.  Not globally handled (like for anything and everything)
        but for the movable modal dialog, if it completes and HAS is in the background,
        notification occurs.  it's not total and great NM support, but demonstrates
        how it works.

ADDED:    If there is no printer selected (should never be a problem, but i ran into it
        on a brand new never used nor touched before PowerMac), window sizing stuff
        (being based upon the printer paper/page) is initialized to other values so
        you can see the window you create

ADDED:    Splash screen

ADDED:    "Registration" dialog

ADDED:    A Show Clipboard window.  since it's just a WASTE instance, it will show anything a
        WASTE window can (embedded objects, PICTs, snd, SOUP, etc). STILL TO DO!  add
        contents identifiers so users can know what's on the clipboard (just like showing
        the clipboard in the Finder)

FIXED:    Drag and drop now works right for PICT, snd, hfs and various other SOUP stuff.
        Still need to get other WASTE Object Handler routines implimented, and also
        see about patching the HFS stuff to optionally read in the file instead of
        inserting a spec (see above notes).

FIXED:    If the user double-clicks (opens) the preferences file, HAS will no longer attempt to
        read in the prefs file as if it was a "regular document".  Going along with this,
        the error handlers are much better now (more readable and userfriendly) so that if
        a file that is not TEXT nor ttro is trying to be read in, the user gets a more
        informative message that it's not a TEXT nor ttro file.

        Question:  tho the document isn't read in, a window is still created (and becomes
        and untitled window).  Should this be allowed to happen?  I have mixed feelings,
        but probably not (probably just call HsoiDestroyWindow() or something in there).

FIXED:    Splash screen mouse clicks no longer click through to the Finder (or whatever).  Added
        a couple FlushEvent() calls before and after !Button() was called in HsoiDoSplashScreen()

FIXED:    A strange "bug".  In HsoiDoOpen(), i typoed; sometimes the variable was modalfilter (as
        i declared) and sometimes modalFilter.  The MW C 68k compiler NEVER caught it, but the
        PPC compiler did.  Changed all things to be more workable and consistant.

ADDED:    More Gestalt checks (and global Boolean's, if necessary, for checks on system manager
        availability).  Most notably, added edition manager checks and notification checks.

FIXED:    Clicks to windows in the background that have a selection range are not automatically
        brought to the front now, if a drag is started.  Bascailly, if you have a window with
        a selection range, this window is in the back (!FrontWindow()), you click in the
        selection range on the back window and start a drag, the window remains in the back
        and the drag is allowed to occur.  My problem was that in the event dispatcher, I
        first would check if window != FrontWindow() SelectWindow( window ) else HsoiDoContentClick()
        But that was wrong.  I changed it so that SelectWindow() is now only called if
        HsoiDoContentClick() returns TRUE.  This allows for better drag-and-drop stuff.
        I also (tho dunno if this affected the thing, but probably did) changed something in
        HsoiDoContentClick from: PtInRgn() & WaitMouseMoved()  : to : ... && ...   I figure
        there was something in the P2C translation that i missed and did bit AND instead of boolean
        AND

IMPROVED:    Error handling is more robust and user friendly (in terms of the error messages).
        Errors are checked for more often, and unkosher situations are better dealt with
        (e.g. if something was NIL, but not worth an error alert).

ADDED:    Marco Piovanelli's MovableModal Library 2.0.  This is a wonderfully small yet
        effective way to handle movable modal dialogs.  I have it being used to handle the
        "Other Font Size..." dialog box (yet another way to do a movable modal dialog).
        I can't get the menu bar stuff to work, but the MovableModalDialog() call works great,
        so I'll just stick with calling that and work on the menu bar stuff later
        (i don't want the edit menu enabled anyways, at least until i get a more robust
        filter working).

UPDATED:    Moved to CWASTE 1.1r16, which is the "final" release of CWASTE for a while.  it's
        the port to bring CWASTE up to date with the final release of WASTE 1.1

ADDED:    In the other font size dialog, and in the prefs dialog stuff that deals with text
        size, I attempted to make them robust enough to stop illegal font size entries before
        the user would hit return, but that didn't work too well...it's not impossible, just
        too difficult to bother with for the scope of this project right now (maybe later).
        So, i just added something that if they hit OK or they try to move to another
        dialog (in the prefs, they click on a new popup), the size is checked for...if it's
        an illegal size, we vomit and don't let them progress until they fix it.

MODIFIED:    When a drag is performed from like Finder to app window (i.e. flavor type HFS),
        if the data type is of type TEXT or ttro, the file will now be read into the
        document window.  If of another type, an icon will be put into the document.
        Essentially, HsoiTranslateDrag() was reduced to nothing, and HsoiMyReceiveHandler()
        was made more robust.

FIXED:    In HsoiReadTextFile(), if a TEXT file is opened, and this file has a resource fork
        (but no 'styl' and/or 'SOUP' resource...for example, a CW text file), it was putting
        up a resNotFound error (since it did find a res fork but not these resources).  This
        has been fixed so no errors are brought up and the file opens without a hitch.

UPDATED:    Moved to CW7 Gold/Academic.  Required a few changes: gSleepTime is now unsigned
        long (instead of long); PB calls changed to new Sync/Async calls (using new routine
        names); moved to WASTE 1.2a2.1

FIXED:    HsoiForgetResource() and HsoiForgetHandle() weren't ported right...fixed the bugs
        there, should work fine now (else blame Marco *wink*).  Also, changed how
        HsoiGetDialogItemRect() works (takes the rect as an argument now instead of
        returning it).

REMOVED:    A check in the drag tracking and receiving handlers that checked for read-only
        windows (and would reject the drag).  This functionality is already achieved by
        WECanAcceptDrag() which is called by WETrackDrag() which is called by
        HsoiMyTrackingHandler().  Just redundant code, no need for it.

UPDATED:    Moved to WASTE 1.2a3 (from the preliminary 1.2a3 distribution), WETabs 1.3.
        Moving to WETabs 1.3 necessitated the removal of "HAS MarcoWETabs.c/.h" and
        move from WETabs32.c to just WETabs.c.  Also, any calls to said such routines
        and/or files were updated to reflect the new changes.

REMOVED:    Dean Yu's ZoomCode.  The main accessor routine (ZoomTheWindow()) took a
        WindowPeek as an argument.  Since I'm working for Copland functionality, WindowPeek's
        just can't exist.  It has been replaced by just good old straight toolbox calling
        (and will remain as such until I either rewrite Yu's code or write my own "smart"
        zoom code)

*NOTE*:    I've been attempting to make HAS as Copland compilant as possible, however it's
        just not 100% possible yet since Apple hasn't even made their Universal Headers
        100% Copland compilant yet.  There are just too many problems that can't be fixed
        yet with STRICT macros turned on.  Here's the deal:  STRICT macros will _not_ be
        left on as a normal thing.  However, they will be on to let me begin migrating
        my code over to Copland.  That which I can start to port over I will (e.g. using
        <xxx>Refs, using an accessor function if it exists).  But that which cannot
        yet be ported will remain as it was, however a comment will be put by that line
        of code saying it will be something that would break under STRICT macros. e.g.:
        //COPLAND - the following line breaks under STRICT macros.

REDONE:    Due to much of the Copland rewrites, I totally trashed the old HsoiAdjustMenus().
        I've rewritten it from scratch in a manner that I think is more logical and
        makes life a little easier when it'd come to later expansion of the code.

MODIFIED:    'Hsoi' is the registered (with Apple) creator type for HAS.  I've now also
        added another creator type for the shell: 'HSoi'.  This creator is used for
        the preferences file (and ONLY the prefs file) to allow for the message string
        resource to show if the prefs file is double-clicked on in the Finder.
        (and this creator is also registered with Apple)

CHANGED, MODIFIED, and REMOVED:  James Walker's Show_help code.  I wanted to rewrite
        Show_help to use WASTE instead of TextEdit.  Originally, i thought I could
        keep a lot of the old integrity of Show_help intact, but i had to sacrifice
        a lot of things....so, the help code resembles Show_help somewhat, but a lot
        had to be changed (and in the future, I'd like to do things to make my help
        code get back more towards the original Show_help, but who knows).  Also,
        all the Show_help files and file structure has been removed...everything is
        now in "HAS Help.c"

ADDED:    With the conversion of Show_help, i had to write some UniversalProcPtr's (UPP's)
        for the callback routines.  I also added some #pragma's and stuff around
        the code here and there to ensure struct alignment to 68k and in case someone
        tried C++ compiles with the code (tho i've NO idea how well all this will work
        under a C++ compile)

ADDED:    HsoiZoomWindow().  Taken pretty much right out of Inside Macintosh (with P->C
        translation and Copland functionality added).  It acts the same as ZoomWindow,
        but offers a slight diverence to deal with multiple monitor setups.  I still
        want to have something that makes zooming to stdState go to an ideal document/
        window size, but that'll be later (and will affect window creation, printing,
        zooming, page setup, etc.)

UPDATED:    Moved to WASTE 1.2a4...the life of continual releases and keeping up
        to date with them *smile*.  This required a few modifications:  calls to
        WEContinuousStyle() now take a WEStyleMode variable type (just a typedef'ed
        unsigned short) instead of a short.  For now (in case Marco changes things
        in 1.2a5) i've just typecasted the calls to WEContinuousStyle() as an
        unsigned short.  Also, there was a new macro in WASTEIntf.h for some
        arrow key behaviors...i've added this macro to HAS HsoiHeaders.pch, but
        left it #defined 0.

FIXED:    In the modal dialog, there was a user item proc installed to dim the
        2nd edit text line.  This didn't work on PowerMacs cause it needed a
        UPP (UserItemUPP) for this procedure.  Fixed it pretty simply and things
        now work right.

DONE:    More general cleaning of the code, removal of redundant stuff, general
        tightening up of things.

CHANGED:    The regular about box has been modified.  No longer just a simple
        little Alert thing, but a little more neat...it's now a full dialog box
        that takes advantage of some resources.

ADDED:    the prefs text dialog is a little more cosmetically pleasing (a nice
        UserItemUPP now draws "grouping boxes" around stuff).  But still, i know
        i could overall better redo the prefs dialogs

REDONE:    printing routines.  modeled after Tom Bender's Tex-Edit+ 1.6.3 source.
        most major change: a clone of the WE instance is now used instead of the
        original (and then playing with it and risking the stability and
        integrity of your we instance).  this has also allowed for things like
        page numbering, and double-spaced printing!

ADDED:    Along the above, a printing prefs dialog has been added.  it's also pretty
        neat cause it has icon/control arrow buttons to increment the margin sizes.

KNOWN BUGS:    These are 2 known bugs in the shell (tho there might and probably are more
        albiet hopefully the rest are subtle bugs that'll eventually be weeded out).
        1.  the topic popup menu in the prefs dialogs truncates.  before the printing
        prefs dialog was added, the topic popup would display the full menu item text
        to act as a "title header" to the dialog.  now, the popup "truncates" down
        to just an arrow popup (a small thing).  no idea why this is happening.
        2.  (and this is an old problem, but i now know the exact reason it's
        happening) the text prefs size popup still acts funny.  If you enter an odd
        size in the edit text (like 13, or any size not already on the popup menu),
        when you click then release the size popup, the edit text reverts from being
        13 (or whatever) to 9.  I know why it's happening, i just can't think
        of a way to fix it (well, i think i can, but it's messy).  As for the
        first known bug, i probably won't fix this.  I found some neat sample code
        on how to impliment multi-pane dialogs (like in the CW prefs dialog).
        I want to impliment this method of multi-pane dialogs in place of the current
        method, so fixing this "bug" will be moot.

POSSIBLE BUG:  I dunno if this is a bug or just something isn't liking life, but
        sometimes (not all the time, which is why this is difficult to track and
        fix) when you're printing, if you try to hit cmd-. to cancel, sometimes
        it'll cancel no problem, sometimes it gets the cancel message, but continues
        to try to print...it's hard to track down and fix, but i think it might
        be due in part to my idle procedure.

ADDED/MODIFIED:    I've rewritten (again) a bunch of window sizing routines.  First,
        CreateWindow (and anything done to CreateWindow was also done to ShowClipboard
        since they're pretty much identical functions...y'know, i ought to see
        if i could remove all the redundant code and just have ShowClipboard
        call CreateWindow...oops, i remember why i didn't do this, cause of how
        i wanted the window to look...like the Finder's Show Clipboard, and due
        to that, can't just call CreateWindow). ANYWAYS :)
        All that hodge-podge hacking code i used to have to determine the ideal
        window size has been replaced by a few functions that do it all for
        me nice and neatly.  Plus, HsoiZoomWindow can now take advantage of these
        new functions (HsoiCalcIdealWindowSize mostly) to create a standard state
        for the window's to zoom to (upon zoomOut)...no more zooming the window
        and totally filling up the screen!

•        (based upon this "ideal window size" stuff, i have an idea.  since the
        size of the window is based upon printing stuff (like the size of the
        printer paper and margin settings), i thought it'd be nice to save a
        printer record in a custom resource in the document's rsrc fork.  if
        the user reopened the document later, their printer settings could be
        restored, their window size be the same, etc...a nice and cool thing to do.
        but also, since window and printing stuff is based upon the margin
        settings, this could all be an effort for nothing...basically, i'll have
        to change everything so that the user can have a global margin setting
        (as it is now) but also document specific margin settings.  that'd
        really be prime and cool to do, but to impliment all this would require
        such major changes to all of the code.  I do want to do it, but right now,
        there are other things for/in the shell that are more important to do.
        if this bugs someone a whole lot, lemme know and I'll see if i can
        impliment it for another release of HAS, or i could let them know the logic
        and method(s) for implimenting such a thing.

FIXED:    In HsoiDoMenuCommand(), under case mEdit, i had it such that if FrontWindow() == nil
        to just break...saved some overhead of going through the rest of the calls to
        just find out later you'd return (could save some time due to jump table access, etc).
        Well, this was fine and good cause i was originally thinking to save the overhead
        cause with no window, you couldn't edit anything anyways.  Well, this was my
        reasoning before i added the Show Clipboard command to the Edit menu. :)  With
        this setup, even if the Show Clipboard item was enabled, it'd do nothing, and
        that's silly.  So, i fixed the DoMenuCommand-case mEdit stuff so that old
        integrity remained, but the Show Clipboard stuff could now happen.

ADDED:    A VBL task of a spinning/animated cursor!  it's pretty groovy!  derrived from
        Inside Macintosh:Processes (there was some sample code).  i've stuck calls to
        it at very intensive times, such as file reading in and writing out and
        times when certain WASTE functions like WECopy, WEPaste, WEInsert, etc.
        Also, a lot of modification had to be done to get this to work on PowerMacs.
        That's been done in a happy way and things should compile and run just peachy
        on either 68k or PPC Macs.

FIXED:    Had a bug in the HsoiShowClipboard() function.  if the clipboard window had
        been shown already (and had something on it) then the clipboard window was
        shown again but this time the scrap was empty/unknown, the clipboard window
        would then show up with the previous contents on it!  not good!  just added
        code to make sure that if the scrap was empty to make sure the clipboar
        window's WE instance was deleted anyways.

KNOWN BUG:    I dunno who to classify as "responsible" for this bug.  When testing my
        VBL spinning cursor, I wanted to create a HUGE file to read in (long time to
        read in meant for sure my VBL task would run cause i was then installing my
        VBL cursor only around HsoiCreateWindow).  To make this file, I took my
        help document, select all, copy, move to the end of the file, paste, select all,
        copy, etc etc.  Worked fine.  When i had a file about 850k (700k text, 150k
        resources), i couldn't do this anymore!  After tracing down the problem, it's
        in WECopy() when PutScrap() is called...PutScrap returned memFullErr (-108)
        hence stuff failed, the clipboard was already zeroed out, and we "lost" our
        copy (and hence ability to paste anything).  But who's fault/problem is this?
        mine?  WASTEs?  I do use temporary memory, but perhaps that's not enough.
        I tried jacking the app's memory partition WAY up..and then things worked, but
        lord, that hogged a LOT of memory (both in my app heap and the system heap
        for such a huge scrap).  So, it's not really WASTE's problem, but perhaps I ought
        to impliment something in my copy/paste/cut/clear routines to check for
        errors, esp. memFullErr and if so, throw up an error explaining the problem and
        what they can do (quit, increase memory, do it again)

ADDED:    A Windows menu.  allows windows to be stacked or tiled.  also creates a running
        list of all the open windows.  based upon code by Scott Knaster and Keith Rollin
        (with lots of modifications).

REDONE:    Again....the HsoiAdjustMenus() function.  i broke it down somewhat for much
        easier management.  Now different cases are handled differently and, IMHO, a little
        better overall.

UPDATED:    Moved to WASTE 1.2a5.

UPDATED:    Moved to CW8 Academic/Gold.  However, using the 1.4 IDE...tho i think the
        1.5b2 IDe is WAY cool, I don't want to use it yet until it's final and stable
        (what good is a compiler that crashes and leaks on you?).  When the netborne
        patch is released, i will move to 1.5.  Besides, to facilitate all this, Metrowerks
        did make it so that the 1.4 and 1.5 stuff is compatabile with each other.
        nice thing!  kudos to Metrowerks for making our lives a little less hellish
        than it already might be, and giving us the ability to have a little fun :)

FIXED:    Some problems in the About box...needed to detach the resource handles before
        i used them.  However, tho i can work fine on 68k Macs, on PowerMacs, you can
        display the about box once, but the next time you do, crashola.  type 3 error,
        illegal instruction.  still can't find the reason...working on it.

FIXED:    certain cmd-key combos were getting mapped to the screen, not the menus!
        i think i might know the problem...i used to check if (isCmdKey && key > 0x32)
        to get printable characters....well, 0x32 is the character '2'.  however,
        in decimal, 32 is the space character (hex 0x20).  if i remember right, this
        was code based upon/from Gary Little's System 7 book...i think it's a boo
        boo and probably accidentally mixed the decimal and hex values up.  now,
        anything that is a cmd-key with a printable character is mapped to the menus

FIXED:    added a line in HsoiDoContentClick so that dialog windows and DA windows
        would not fall through into the WEClick stuff...that can cause some serious
        problems!  we also check to make sure the WE instance is valid (!nil) before
        proceeding

REMOVED:    the HsoiBringUpDialogSoDeactivateFrontWindow/DownDialogUpWindow stuff.
        the name was too damn long and the function was just the same as going:
        HsoiDoActivate( true/false, FrontWindow() );  so, it was silly.  all
        calls have been replaced and things should be neater now.

FIXED:    some potential bad problems with HsoiReadTextFile().  before WEInsert()
        was called, the style and soup handles were getting locked.  but in
        a previous statement, there was the possibility of those handles getting
        set to NIL and then possibly passing a nil handle to HLock.  the memory
        manager wouldn't like that.

FIXED:    another problem with HsoiReadTextFile().  the forkRefNum's never got
        set to zero upon the fork being closed.  this was a problem since
        at the end of the function, we check if the refNum is > 0 and then
        close the fork if it is.  this was setting up a situation where the fork could
        have been closed 2 times.  again, not a good thing.  fixed by making sure
        that any time the files were closed before the funtion's end clean up
        stuff was called, the refNum was set to zero immediately after calling
        the close on the fork.  Both this and the previous bug fix were found
        by Chris Thomas who was using the WASTE Demo app...and since that was
        copy/pasted code from HAS, I had to fix it in here also.

FIXED:    A bug in Michael Kamprath's WASTE Object Handlers's sound handler.  the
        routine, SoundIsPlaying() had a not operator (!) in an if statement that
        was wrong...the function then checked and returned improperly.  this
        also required adding a not operator to the CheckSoundStatus() function
        to make that one work right.  All things now seem to be working right,
        the sound menu adjusts correctly, life seems good (but i'm currently
        waiting to hear back from Michael about his thoughts on the change/fix)

FIXED:    a dumb bug (ah, the fun of copy and paste) where in the clipboard window's
        menu adjustor code that the ability to record a new sound was enabled.
        it should never be enabled since this is the clipboard window!

FIXED:    forgot that if we don't have a prefs file, we need to write one!  so, in
        HsoiInitPrefs, if sNewFile, gWritePrefs = true.  oops.

ADDED:    Text to Speech capabilities.  based upon Tom Bender's Tex-Edit+ 1.6.3
        code (note the user-level similarities...pretty much exactly the same thing.
        code level similarities are high, but i did have to modify a bunch to
        get it to work in C).  made a few changes (both user and code level), most
        notably is a more robust dialog filter.

FIXED:    a bug where if the Clipboard window was open but was not front window (and
        just whatever other kind of window was in front), if the clipboard window
        was brought to the front by clicking on it, it would not update the contents
        of the window (i.e. if there was something new on the clipboard, clicking it
        to the front would not have the new scrap contents, but would contain the
        old scrap contents)

FIXED:    Along with the above fix, it added another bug in the mouseDown event
        handler (for content clicks).  if the clipboard window was front and
        you clicked in it, it would redraw instead of selecting a word.  fixed.

FIXED:    If a window with a WASTE instance is front, it is read-only (for whatever
        reason: ttro, Clipboard window, toggled in the Features menu, etc),
        due to precompiler directives the caret is hid (in a read-only instance),
        and we have speech turned on, then "Speak from Cursor" is disabled since
        there can never be a caret in the window from which to speak from.

--------- Known Bugs ----------

This probably isn't a complete list, but it's something...

•    trying to cancel printing with cmd-. doesn't always work...it seems that the cancel
    gets picked up, but then is ignored.  This is also a bug i found in Tex-Edit+ 1.6.3
    (since the code was based upon that).  so maybe if Tom fixes his, or I fix, let
    the other know.

•    the topic popup in the prefs dialog(s) truncates when a new dialog is brought up.
    not a bug worth pursuing since the prefs code will soon be totally rewritten to
    have multipane dialogs with icons, etc (like the CW prefs dialog).

•    in the text prefs, the size popup and edit box:  put an "odd" size in the edit
    box, popup the menu, select nothing (or the appended new/odd size) and then
    the number in the edit box changes to 9 (the first regular item in the popup menu)

•    during some HFS drags (drag a Finder icon into an open window), freezes or crashes
    occur.  this bug is within (as far as i could tell) the WASTE Object Handler code,
    something with the GetFileIcon stuff.  Also, reading in big PICTs seemed to cause
    some same similar problems...perhaps shortcomings with the Scrap Manager and
    lack of memory in the system heap.

•    running native PPC code on a PowerMac, you occasionally get type 3 errors.  It seems
    that it only happens when dialogs are brought up.  I've had it happen when the
    regular about box is brought up the second time (first time works ok), when alerts
    come up.  It seems it might be linked to my dialog filters (especially ones that
    use the hsoiMyStandardDialogFilter), but I don't have the facilities to adequately
    track it down (i.e. I don't own a PowerMac).

•    A type 3 error also occurs when you are running native PPC code on a PowerMac, you
    have speech on, you're speaking text, and you're hiliting by word (none and by
    sentence seem to work ok).  I think this problem has to do with the A5 world. but
    strangely, it seems that Tom Bender's same code works fine on PowerMacs...